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1 Technical Field 

End-user quality of service optimisation for packet switched services In a mobile 
network, such as WCDMA, CDMA2000, GPRS, and WLAN. 

The invention Is applicable for the patent applications "Method and apparatus for 
network initiated rate control for P2C services in a mobile system" 
(PCT/SE03/00022) and "Method and apparatus for network initiated rale control for 
P2P services In a mobile system" (PCT/SE03/00026). 



2 Technical Bacl^ground 

2.1 The Problem Area 

The afore-mentloned two Inventions enhance the QoS (Quality-of-Services) and QoE 
(Quality-of-end-user-Experience) for operators and end-users. However, they do not 
fully address how the rate control services shall be set-up in general, nor do they 
bring up how to deal with addressing issues in particular. 

2.2 State of the Art 

The need of Layer-2 triggering Rate Control (RC) mechanisms has recently been 
Identified as an important step to providing good QoS and QoE in 2.5/3G wireless 
networks. Thus, Ericsson promotes such solutions for our products, as well as In the 
standardization (3GPP). 

Since this area is new and Important, certain aspects of the RC services, such as 
how to set them up (e.g. how to provide the Radio Network Controller .(RNC)/Base 
Station Controller (BSC), or other types of radio network control nodes) with correct 
data for addressing issues), have not been fully dealt with. 



3 The Invention 

3.1 Summary 

The main principles of the present idea are the following: 

The invention identifies and solves the set-up/addressing problems for Network 
initiated Rate Control services, as presented in PCT/SE03/00022 and 
PCT/SE03/00026, for different deployment scenarios. In future scenarios, radio 
network control nodes such as eg. RNCs and BSCs are associated with IP 
addresses, whereas according to present scenarios these are un-associated with IP 
addresses. Moreover, the radio network control node can be pre-configured 
beforehand, as well as being configured with the aid of the user equipment (UE), or 
the application server, or the application server proxy, or the Media Gateway. Last 
but not least, the disclosure is divided into two main traffic scenarios, person-to- 
content (P2C) and person-to-person (P2P). 
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3.2 Description 

3.2.1 Introduction .... 
The Invention Is outlined In the following way: 

First we go through how the RC service is set-up and how the addressing is 
solved, i.e. how the source knows where to send the Rate Control (RC) 
messages, for different scenarios in a Person-to-Content (P2C) services 
context. 

Therafter, we do the same for Person-to-Person (P2P) services. 

3.2.2 Set-up of the RC service for P2C communication 
Concerning streaming, the Rate Control service may be setup for: 

1. every media stream in the SDP description. E.g., one RC service 
setup for the speech stream and one RC service setup for the video 
stream. 

2. all media stream in the SDP description as a whole. 

3. any combination of 1 . and 2. • 

3.2.2.1 Pre-configuration of the radio network controlling node (RNC/BSC) 

Figure 1 below outlines an architecture in which the RNC is pre-configured to 
manage the RC service. The receiver of the Rate Control indications is 
typically, but not necessarily, a Proxy, The RNC may be hard-coded or 
configured with data that is necessary for the semce by a configuration tool. 
Examples of such configuration data are: 

• Receiver's (Proxy's) IP address and Port number. 

• The traffic class for which the RC service shall be applicable (e.g. 
Streaming and Interactive). 

• Which users that shall have the service. This may be based on the 
subscription. 
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Figure 1 Architecture for Rate Control services for P2C trafflc. 

The below signalling diagram. Figure 2, outlines how the above described 
set-up procedure works for a pre-configured radio network controlling node. 
This procedure configures the RNC to send bandwidth (Rate Control) 
indications to the Proxy, via GGSN, for a specific traffic class (e.g. 
Streaming). 

The RNC puts together an IP message and tunnels It over e.g. the GTP-U 
protocol via GGSN towards the Proxy. However, since the Proxy has no 
knowledge which session (i.e.. which UE) the Rate Control message is valid 
for. It needs to resolve the UE's IP address and Port number. This may be 
done via the GTP-U Tunnel Endpoint Identifier in the T-PDU message and 
TFT filter mapping. (See Section 4 for explanatory notes on protocols.) 
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3.2.2.2 



GTP-U: Rate Contrst Feedback 




Resolving the IP address ani 
Port number of the UE 





omJ !'^^"'P!® of a signalling diagram on how the addressing issue is solved when 
the RNC IS configured to send Rate Control indications fora spldfic selston 

When the GGSN receives the Rate Control message from the RNC it 
resolves the UE's IP address and Port number, e.g via the GTP-U Tunnel 

tSI? m«? ?h^'°^ 2'-°^°^ ^"^ TFT filter parameters t3GPP 

TS 24 008]. Therea er, ,t relays the Rate Control Indication to the Proxy wUh 
inclusion of the UE's IP address and Port number. I.e.. the Rate Sntr^ 

rourSymplTli? Ihh"^'' ^TL^^^^ ^^T^^'^*^ alr-interface and the 

source s (UE s) IP address and Port number. By including the UE's IP 

^hThtrss^?^^^^^^^^ ^'^^^^^^ --on 

The UE sets up the (RNC/BSC) upon PDP context establishment 

The below figure illustrates how the UE may set-up the RNC with needed 
parameters for the Rate Control service. In this example we use a Pro^ and 
a Streaming Server to illustrate the principles. ^ 
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Figure 3 The UE sets up the RNC with needed parameters for the Rate Cor^trol 
service. In the above example, it is the Proxy that adds the specific RC parameters to 
the RTSP/SDP protocol. The RNC may or may not have an IP address of Its own. 



A specific identity (ID) has been added for the sake of RC Rate Control 
service, (i.e., the RC ID). 

In the above example the RC IP address and RC Port number correspond to 
the Proxy's IP address and Port number. 

Note that in presence of NATs (Network Address Translators) it Is crucial that 
a special identity for the Rate Control service be in place in order to have the 
RC service working. The reason is the following: the UE IP address and Port 
number are operator specific (i.e., they are only locally known) and cannot be 
used by the Server as Rate Control service Identifier. 

In case of TCP based traffic the set-up parameters may e.g. be included in 
the HTTP header by the Proxy or the Server. Another alternative maybe more 
suited for general TCP traffic Is to pre-configure the UE with the RC IP and 
Port. 
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3.2.2.3 The Proxy (or the Server) sets up the (RNC/BSC) upon PDP context 
establrshment. 



The below figures 4 and 5 illustrate how the Proxy may set-up the RNC with 
needed parameters for the Rate Control service. In this example we use a 
Proxy and a Streaming Server to illustrate the principles. 



In the first scenario, ie Figure 4, we assume that the RNC Is not associated 
with an IP address. In this case the UE is totally unaware of the RC service. 



UE RNC SGSN GGSN Proxy Stream Ser 
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Figure 4 The Proxy sets up the RNC. The RNC has no IP addresses of its own. 



This scenario requires that the RNC and the Proxy be pre-conflgured by 
means of a configuration tool with RC port number. This RC port number 
should be used by the Proxy as a source port number for all RC messages. 
The RNC uses the RC port number to single out RC messages, I.e. the 
messages that have source port number equal to the RC port number- 
After RTSP initial signalling, the UE establishes the secondary PDP context 
TFT packet filters In such a way that it includes only the user data flow, as the 
UE Is unaware of the RC service [see 3GPP TS 23.060]. 

The Proxy initialises the RNC. In order to perform that, the Proxy sends an 
Initialisation message whose IP/UDP header contains: UE IP address and 
user data port number as destination address and port, the source port is the 
RC port number (pre-configured) and source IP address Is the Proxy's IP 
address. The message t;ontains the following parameters: 
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• RC IP address (Proxy IP address) 

• . RC port number (Port at which Proxy will listen to RC messages) 

• RC ID. 

GGSN maps the incoming initialisation message to the PDP context carrying 
the user data flow (i.e. the PDP context carrying the data to be controlled) 
since the IP address and destination port number of the RC message equal 
the ones of the user data. 

RNC "sniffes" all the incoming traffic of that particular user and intercepts the 
packets that have the RC port as source port, i.e. RC messages. The RNC is 
able to bind the RC message with correct Radio Access Bearer (RAB) 
because the RC message has arrived from that particular RAB. 

In UL, RNC sends the RC Response message to the RC IP address and RC 
port number (i.e. to the Proxy), The message contains initial bit rate and RC 
ID. 

The Proxy uses the RC ID for binding between RC message and RTSP 
session. 

In the second scenario (see Figure 5) it is assumed that the RNC/BSC has its 
own IP address and that the Proxy knows this. The Proxy may e.g. retrieve 
the RNC/BSC IP address from the UE upon RTSP/HTTP Session 
establishment phase. (We assume that the UE continuously gets updated 
with regard to the RNC/BSC's IP Address/Port number, for which It has 
established a PDP context). 

In case of inter-RNC/BSC handover, the mobility management procedures 
ensure that the "new" RNC/BSC gets updated so that the RC service 
continues without any interruption. 
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3.2.3 



Figure 5 The Proxy sets up the RNC with needed parameters for the Rate Control 
service. Note that the RNC has an IP address of Its own. 

After initial RTSP signalling exchange and finalising of the PDP context 
establishment procedure, the Proxy signals spiecific RC parameters (RC ID, 
RC IP address, RC port number, UE IP address and UE data destination port 
number) to the RNC. The RNC has to bind the RC ID with the RAB for the 
session to know where to send the RC messages. In order to achieve this the 
RNC "sniffs" for every RAB the user data flow thereby extracting the UE IP 
address and UE data destination port number. This information Is used to 
bind the RC ID with the proper RAB. 

Set-up of the RC service for P2P communication 

The general architecture for P2P services is depicted In Figure 6. 
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Rgure 6 As can be seen from the architecture the Rate Control (RC) message may be 
sent from an RNC to another RNC in the mobile network or to an "equivalenr node in 
the fixed network (e.g. a Media Gateway). One can also see that the Rate Control 
messages between two UEs may traverse an intermediate node (e.g. a Proxy). 



3.2.3.1 The UE sets up the RNC/BSC 

The principles are the same as for P2C services. E.g., the RNC needs to be 
configured with equivalent parameters as in the P2C case. 

In the first scenario, see Figure 7, the RNCs have no IP addresses of their 
own and they must therefore be set-up in a slightly different manner 
compared to the above case. 
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Figure 7 The Ues set up the RNC, The RNC has no IP address of its own. 

The RC IP address and RC Port number correspond to the UEs IP address 
and Port number, respectively. 



The UE-A starts by sending an INVITE message to UE-B. This message 
contains the SDP file, which describes the UE-A characteristics. The file 
contains, among other things, RC parameters (ID, IP address and Port 
number) and an attribute Indicating that UE-A supports RC service. This 
attribute may be utilised by UE-B in order to indicate to RNC-B that UE-A Is 
attached to the RAN supporting the rate control service. UE-B replies with a 
message containing its session description with the same information. 

Once UE-A and UE-B know each other's session characteristics they start the 
PDP context activation procedure. The UE-A PDP context request message 
must contain the RC parameters of UE-B. This information is forwarded to 
the RNC-A by the SGSN-A by means of RANAP RAB Assignment Request 
message. The UE defines TFT packet filters of secondary PDP context in 
such a way that it includes RC messages (i.e. the incoming RC messages will 
be mapped onto this secondary PDP context). 
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When RNC-A receives the RANAP message, containing the RC parameters, 
it understands that the available DL-A bit rates must be communicated to a 
remote entity. RNC-A uses the RC IP address (IP address of UE-B) to route 
the lu UP Initialisation message towards UE-B. RNC-B uses "sniffing*' 
technique to intercept the message as all traffic to UE-B will pass through 
RNC-B. "Sniffing" means that the RNOB listens to the user data traffic from 
UE-A to UE-B and intercepts messages that are marked, e.g., an RC ID field 
in the lu UP protocol or destination port number In IP header, to facilitate the 
RC service. The message contains the DL bit rates available over air interface 
A. RNC-B is able to bind the RC message with correct RAB because the RC 
message has arrived from that particular RAB. 

In the second scenario. Figure 8, we assume the RNCs have their own IP 
addresses/port numbers and that the UE continuously gets updated with 
regard to the RNC/BSC's IP Address/Port number, for which It has 
established a PDP context. 



As in the previous illustrated examples for P2C services, the RC ID is used to 
bind the application session with the RAB. In this scenario the RC IP address 
and RC Port number correspond to the respective RNCs IP address and Port 
number. The figure below. Figure 8, discusses the principles. 
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Figure 8 The Ues sel-up of the RNCs to enable the Rale Control Service. Note that in 
the above example, the RNCs have their own IP addresses and Port numbers. 
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The RNCs are set-up with the RC ID, the IP address, and Port number of the 
corresponding RNCs. Thereafter, the RNC-A may e.g. indicate to RNC B that 
it has shortage/spare radio resources in the DL, by sending a Rate Control 
(RC) message to RNC-B. The message contains RC ID and bit rate value. 
The RNC-B binds the RC message with a proper RAB basing on RC ID. 

The same mechanism Is used in the reverse direction (i.e. from the RNC-B to 
the RNC-A). 

Note that If UE A moves to another controlling RNC (say, an RNC-C), the 
mobility management procedures ensure that the new and corresponding 
RNCs are updated with necessary data (e.g. new/updated RNC IP 
addresses/Port numbers) to continue the Rate Control sen/ice without any 
interruption. 



3.2,3.2 



The Proxy sets up the RNC/BSC 



lu Ul >: RC Request (RC ID; RC IP addr sss; RC Port Numbe 



In the first scenario. Figure 9. we assume that the RNC is not associated with 
any IP address. In this case the UE Is totally unaware about the RC service. 
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Figure 9 The SlP-Proxy(s) (the CNs must not share the same Proxy) set up the RNCs 
to enable the RC service. The RNCs have no IP addresses of their ovm. 
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This scenario requires that the RNC and the Proxy be pre-configured by 
means of configuration tool with RC port number. This RC port number 
should be used by the Proxy as source port number for all RC messages. 
The RNC uses the RC port number to single out RC messages, i.e. the 
messages that have source port number equal to the RC port number. 

In this scenario the Proxy Is used for initialisation of RNCs only. 

UE-A initiates the application session by sending an INVITE message to UE- 
B, via the SIP-Proxy. The message contains, among other things, the SDP 
file, which specifies the rates that are applicable for the session. 

After initial SIP signalling, the UEs establish the secondary PDP contexts TFT 
packet filters in such a way that they include only the user data flow, as the 
UEs are unaware of the RC service [see 3GPP TS 23.060]. 

As the Proxy is a SIP Proxy it intercepts the SIP messages and thereby gels 
to know all the information about the UEs and session. AftenA^ards it initialises 
the RNCs. In order to perform that, the Proxy sends an Initialisation message 
to UE-A and UE-B IP destination addresses and user data port numbers as 
destination port; the source port is the RC port number (pre-configured) and 
source IP address is Proxy IP address. The message contains following 
parameters: 

• RC IP address (peer UE IP address) 

• RC source port number (Proxy could choose port at which peer RNC 
will listen to RC messages) 

• RC ID. 

GGSN maps the incoming initialisation message to the PDP context carrying 
the user data flow (i.e. the PDP context carrying the data to be controlled) 
since the IP address and destination port number of the RC message equals 
the ones of the user data. 

The RNCs "snifr all the incoming traffic of that particular user and intercept 
the packets that have the RC port as source port, i.e. RC messages. RNCs 
are able to bind the RC message with correct RAB because the RC message 
has am'ved from that particular RAB. 

In UL, RNC-A sends the RC Initialisation message to the RC IP address and 
RC port number (i.e. to the UE-B). The message contains initial bit rate and 
RC ID. 



GGSN-B maps the incoming initialisation message to the correct PDP context 
since the IP address and destination port number of RC message equals the 
user data flow. 
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RNC-B, upon "sniffing" all the incoming traffic of that particular user, 
Intercepts the packets that have the RC port as source port, i.e. RC 
messages. RNC Is able to bind the RC message with correct RAB because 
the RC message has arrived from that particular RAB, 

RNC-B replies to the Inltlalisatron RC message In the same way as described 
above. 

In the second scenario, see Figure 10. the RNC has its own IP address and 
the local SIP proxy has knowledge of it I.e., we assume that the Proxy 
continuously gets updated with regard to the RNC/BSC's IP Address/Port 
number, for which UEs have established a PDP context. The RNC address 
could alternatively be received from the UE. 
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Figure 10 The SIP-Proxys set up the RNC for the RC sercvice. The RNCs have their 
own IP addresses. 

UE-A initiates the application session by sending an INVITE message to UE- 
B. via the SIP-Proxy. The SlP-Proxy adds the RNC-IP address and Port 
number to which the UE is connected to the SIP message. The SDP file 
specifies the rates that are applicable for the session. If it is the UE that 
knows of the RNC IP, then the UE adds this information to the SIP message. 
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3.2.3.3 



Once UE-A and UE-B know each other's application session characteristics, 
they start the PDP context activation procedure. Thereafter, UE-A sends a 
SIP acknowledgement to UE-B. via the SlP-Proxies (one or several such 
proxies). The SIP-Proxies intercept this message and issue the Rate Control 
service by sending RC Request messages to its local RNC. These messages 
contain specific RC parameters (RC ID, RC IP address, RC port number, UE 
IP address and UE data destination port number). The RNC has to bind the 
RC ID with the RAB for the session to know where to send the Rate Control 
messages. In order to perform that RNC "sniffs" for every RAB the user data 
flow thereby extracting the UE IP address and UE data destination port 
number This information Is used to bind the RC ID with the proper RAB. 

The Media Gateway sets up the RNC/BSC 



In other words, this scenario is about a set-up of the RC service for mobfle-to- 
fixed phone communication. 

This P2P case can be viewed as P2C case where the Proxy is replaced by an 
Media Gateway (MGW). See 3.2.2,2 and 3.2.2.3. 

The MGW performs transcoding functionality between PLMN and PSTN. 
Thus the RC service Is used to properly set the transcoder's bit rate. 

Case 1 : The UE sets up the (RNC/BSC) upon PDP context establishment 

The below figure 1 1 illustrates how the UE may set-up the RNC with needed 
parameters for the Rate Control service. 
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Figure 11 The UE sets up the RNC with needed parameters for the Rate Control 
service- In the above example, it is the MGW that adds the specific RC parameters to 
the SIP/SDP protocol. The RNC may or may not have an IP address of its own. 

The RC set-up ?n this case is quite similar to one described in section 3.2.2.2. 
The only difference is that the SIP protocol, instead of RTSP, is used to set 
up the session and thus the RC parameters are sent to the UE in the SIP OK 
message. 

Case 2: The MGW sets up the (RNC/BSC) upon PDP context establishment 

The below figures 12 and 13 illustrate how the MGW may set up the RNC 
with needed parameters for the Rate Control service. 

In the first scenario, fig. 12, we assume that the RNC is not associated with 
any IP address. In this case the UE is totally unaware of the RC service. 
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Figure 12 The MGW sets up the RNC. The RNC has no IP addresses of its own. 



The RC set-up in this case is quite similar to the first scenario described in 
section 3.2.2.3. The only difference is that the SIP protocol. Instead of RTSP, 
is used to set up the session. 
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In the second scenario (see Fig. 13) it is assumed tliat the RNC/BSC has its 
own IP address and that the MGW l<nows it. The MGW may e.g. retrieve the 
RNC/BSC IP address from the UE upon RTSP/HTtP Session establishment 
phase. (We assume that the UE continuously gets updated with regard to the 
RNC/BSC's IP Address/Port number, for which it has established a PDP 
context). 
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Figure 13 The MGW sets up the RNC with needed parameters for the Rate Control 
service. Note that the RNC has an IP address of its own. 



The RC set-up In this case is quite similar to the second described in section 
3.2.2.3. The only difference is that the SIP protocol. Instead of RTSP, is used 
to set up the session. 
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4 Brief Protocol Descriptions 

A number of protocols are referred to throughout this disclosure. For the sake 
of clarity, a set of brief explanations is listed below: 

^ RTSP 



RTSP is an application-level protocol for control of the delivery of data with 
real-time properties. It permits to establish and control either one or several 
time-synchronised streams of continuous media such as audio and video. 
Source of data can include both live data feeds and stored clips, RTSP acts 
as "networl^ remote control" for multimedia servers. 



SIP 



SIP is an application level protocol used to set-up P2P multimedia sessions. 
Initial SIP messages contain SDP object describing the session's 
characteristics (e.g. IP addresses, port numbers, codec types etc.) 

GTP-U 



GTP is a GPRS Tunnelling Protocol. It provides a tunnelling of user data and 
signalling between SGSN and GGSN. 

In the user plane, the GTP-U protocol entity provides packet transmission 
and reception services to user plane entities In the GGSN, in the SGSN and, 
In the case of UMTS systems, in the RNC. Moreover GTP-U canies lu UP 
messages. 



lu UP 



The lu UP (lu User Plane) protocol is used to convey user data associated to 
Radio Access Bearers. In "support mode" lu UP protocol may provide Radio 
Access Bearers (RABs) with particular features in addition to transfer of user 
data (e.g. Initialisation, Rate control etc.). 

In general, lu UP protocol instances exist between CN (SGSN or GGSN) and 
UTRAN (RNC). However, If the lu UP protocol instances operate in support 
mode the lu UP protocol instance may either be located within another 
UTRAN (remote RNC) or within an entity that is not the serving CN node of 
'i the UTRAN (e.g. Proxy or Media GW). 

SM 

The SM (Session Management) protocol provides establishment, modification 
and release of POP context and controls the QoS between UE and GGSN. 
POP context is stored In the UE, the SGSN, and the GGSN. 
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From addressing perspective, the relevant entry in the PDP context is the 
Traffic Flow Template (TFT). A TFT Is basically a packet filter, associating 
downlink packets to the correct PDP context for putting packets in the correct 
GTP tunnel. 



RANAP 

RANAP Is the protocol that provides the signalling between RNC and SGSN. 
It Is responsible for setting up, modifying, and releasing RABs. 
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: - 6 CLAIM 

/ ' " - • Method for setting up a Rate Control (RC) service in a communications 

network in whicti reside 

• A) at least one mobile station (UE); 

• B) an application server proxy in a Service Network domain and/or, 

• C) an application server in a Service Network domain, and 

• D) a Radio Network control node 

tlie method having the purpose of enabling the proxy to send information/ 
/content to the mobile station (UE) on a pre-selected application session, and 
wherein said method comprises the following step: 

- receiving high-layer parameters (configuration data such as Port number, IP 
address, rate control ID) In the Radio Network control node; 

and the method is, moreover, also characterized by the following steps: 

- tying said high-layer parameters to low-layer parameters (RAB) in the Radio 
Network control node; 

- generating in the Radio Network control node a rate control (RC) message 
including the tied parameters, and 

- sending the generated RC message to the application server or its proxy in 
the Service Network domain; 

The information in the RC control message is thereafter used by the 
application server or its proxy to send content to the mobile station (UE) on 
the pre-selected application session with the right bit rate. 



Read and Understood by:, 
Read and Understood by:. 



4/7/03 



Date: 
Date:. 



Kl/eiP/V/P Elin Vangborg 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



□ IMAGE CUT OFF AT TOP, BOTTOM OR SmES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLACK BORDERS 



